Syst«="n For Remote Loading of Objects Or Files in Order 

To Update Software 

This invention pertains to a system for remote loading of 
objects or files in order to update software, particularly for 
^Vaudiovisual reproduction systems that are triggered by the 
payment of fees, such as jukeboxes or other devices. 

In the prior art, devices for remote loading of an operating 
system through a network. are known such as, for example, from 
British Patent No. 2 231 180. The teaching of this patent 
application calls for loading a first computer, which is 

^ n connected to a second computer via a network, by loading a subset 

f n 

M of the operating system into the memory of the first computer, 

f!i whereby^ sibtdb subset contains the commands that make it possible 
f ft /\ * 

a to copy files, create a directory, and format a disk, as well as 
b allowing a connection . to operate through the networls so that this 
[j subset can then be used to transfer all of the operating system 
?3 files from the second computer to the disk of the first computer . 

In this type of remote loading, the purpose is to load the 
entire operating system and all of the operating system files. 
This thus limits remote loading either to tying up, for 
relatively long periods of time, telecommunications systems that 
are to carry out remote loading in the case of the operating 
system, or causes the relevant files to have to be updated 
frequently. 
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From U.S. Patent No. 4,958,278 a system is also known for 
remote loading to a terminal that is not equipped with a disk 
player. 

From French Patent No. 2 682 786 another process is known 
for remote loading to a terminal that is not equipped with a hard 
disk. 

^ Finally ,j^a^^s-t- European Patent No. 0 358 992 teaches a 

method for remote loading, via a network, of an operating system 
or of executable files to a computer that does not include a boot 
device or other devices that hold the executable program. A 
H first minimum boot program is transferred initially, and then 
:l: this minimum boot program executes itself, establishes a logical 
H link to a disk of the server, and allows the querying computer to 
[b 1 treat the server -disk as a local boot device. 
Mpcn/ The ob j ect 0 f t h e invention is to avoid the necessity, on 
C3 the one hand, of rebooting the terminal to which downloading is 
U done and, on the other, to make it possible to transfer operating 
£3 files or parts of an executable program without having to 

reinitialize the machine, and doing so while making sure that the 
^-operation of the system is not s :*er degraded by the remotely loaded 
version . 

This object is achieved by virtue of the fact that the 
architecture of the operating system provides for breaking the 
different tasks down into software, modules that are 
interconnected by means of dynamic links or are composed of 
executable subroutines that have main dependence links to other 
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parts of the operating system, whereby each of the modules is 

composed of object files or libraries that are represented by 

dynamic link libraries, which are organized among themselves 

according to a number of dependence levels, as described in their 

respective attributes. 

According to another feature, the attributes of an object or 

a library indicate the version number and the dependencies of the 

object with respect to other objects. 

According to another feature, the attributes indicate the 

levels attributed to the modules. 
I According to another feature, the different tasks include a 

J main task. that includes a module ( JUKECORE) , which is designed to 
3 load the dynamic link libraries (DLLs), to initialize the nucleus 
U of the program, to initialize the graphics management module 

(GFX) , to initialize the library loading module (WDLL) , to load 
3 the Telecom module of the telecommunications tasks (TELECOM . DLL) , 
J and to launch the screen interpreter program as a main task. 
^ According to another feature, the program is subdivided into 

a certain number of modules that define a task that is specific 

to the terminal. 

According to another feature, this specific task is that 

which corresponds to a jukebox and includes a specific main task, 

a certain number of modules that define the "Windows" functions 

of the display, which are the following: 

- a module for running the mouse signals -or the touch 

screen; 
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- a module for running the messages that are exchanged among 
the objects; 

- a "FIL.DJL" module for managing the fiLes on .disk; 

- a "FIL.DJL" module for reading and writing files to ~and 
from disk; * 

- a "FILIO. DJL" module for monitoring all of the events that 
are generated by the hardware, such as the touch screen, the 
sound card, and the money hardware processing interface. 

According to another feature, the main task of the jukebox 
application includes a "SI LOAD. DLL" module, which contains the 
library of- the loader program, whereb^&a4rdr library is intended 
to verify the versions of the dynamic link libraries that are 
requested, to load them, and to call the Telecom task modules in 
order to transfer files. 

According to another feature, ^sa-±¥ SILOAD module includes 
the list in a file (DLL. DEFAULT) of the minimum versions that are 
required for operation, as well as the list' of all of the 
functions that are represented either by the libraries (DJL) 
(DATA JUKEBOX LIBRARY) or by the object files (DJO DATA JUKEBOX 
OBJECT) . 



According to another feature,^ said- object or lxbrary 



contains the list of all of the functions that the library or 
object needs, as well as the version numbers and dependencies. 

According to another feature, WDLL ensures the management of 
- all of the new modules and verifies that the remotely loaded 
modules do not have any missing dependencies and that they have 



4 



been loaded with the necessary versions. 

According to another feature, SILOAD manages' the loading of 
the modules that are specific to the task of the terminal, i.e., 
all of the "DJL" modules already listed above, as well as^ that 
the jukebox library modules constituted by WOBJECT manage the 
object, the mixer, and the purchases; the "WCURSOR" module 
manages the movements of the cursor; the DBMAPI module manages 
the database; the "WFONTS" module manages all of the' font types; 
.fe^e "PARSER/' module analyzes and generates the screens from the 
script and verifies the grammar with the aid of the "GRAMMAR . DJL 
module, and the lexical module "LEXY.DJL." 

According to another feature, the library loading module 
SILOAD includes a "WINDEF" module that contains the list of the 
files that have to be included in order to manage the' windows of 
a Windows display that is supplied on the monitor of the jukebox 
type terminal. 

According to another feature, this list of objects consists 

of: 

- an "OB JET WPSCREEN . DJO" module, which makes it possible t 
define the main page on the monitor; 

- a "WSCREEN . DJO" object module, which makes it possible to 
determine in this main page the number of screens that are 
available and thus to allow multiple windows or screens to be 
displayed; 

- a "WIMAGE.DJO" module, which makes it possible to 
determine and define on the screen the image that it will use; . 




- a "WANIM. DJO" module, which makes it possible to define 
the animation when the image is animated; 

- a "WBUTTON . DJO" module, which makes it possible to define 
and manage the buttons that are used on the screen of the main 
page; 

- a "WLABEL. DJO" module, which makes it possible to create 
the labels that make it possible to write on top of an object; 
and 

- a "WSCROLLER. DJO" module, which makes it possible to 
design the scroll display zones, between two points for example, 

i horizontal, diagonal, vertical. 

1! According to another feature, all of these object modules, 

y 

i which are managed by the main task, use a "JHANDLER" library, 

y which makes it possible to define the fixed uses of -the screens 

n 

and thus to determine which are the interfaces that ensure the 
3 link ,to the different objects that are defined by the preceding 
J modules . 

5 According to another feature, the SILOAD task launches or 

loads the "XCP" module, makes it possible to manage payment tasks 
such as those handled by ticket receiving systems or coin or card 
payment units, and also makes it possible to save the basic 
information in the IBOTTON. 

/ Other features and advantages of this invention will be made 
clearer by reading the description, given below, with reference to 
the attached drawings, where: 
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Figure 1 shows'* a schematic of the electrical diagrams of the 

hardware that constitutes the /; invention;/\Q^ci 

T 

Figure 2 shows a flow chart of the relationships between the 
library modules and the object modules. 

Preferably, but without being limited hereto, the 
audiovisual reproduction system uses the hardware elements listed 
and referenced below. 
/ ^^^ Micropro ce- s sor -central unit 1 is a high-performance PC 
compatible system, whereby during implementation a Pentium-type 
system was chosen that has the following memory resources and 
= specifications: 

I - compatibility with the local VESA bus; 

I - processor cache: 256 KB minimum; 

I - RAM memory: 32 MB; 

- high-performance serial ports; 

I - SVGA microprocessor graphics adapter; 

I - SCSI/2 type bus controller; 

- self-powered static RAM memory. 

Any other central processing unit that has the equivalent or 
better performance can be used in the invention. 

This central processing unit controls and manages a sound 
control circuit (5), -a telecommunications control circuit (4), an 
input control circuit (3), a bulk storage control circuit (2), 
and a display^aeaft©- control circuit (6). The displa^msans 
consists primarily of a flat-screen non-interlaced SVGA 
high-resolution and low-radiation video monitor (62), i.e., this 
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is the monitor that is used to reproduce images (for example, the 
album covers of musical • selections ) , graphics, or video clips. 

^^i^storage g&eatts- (21), which/i^^hard disks of the 
high-speed and high-capacity SCSI type,^*ee- associated with the 
v s±orage iu&afte that^a^e- already present in the microprocessor 



ce. A Tiese--meaiis_-s^4£e -to store digitized and compressed 



/: audiovisual information. 

A high-speed telecommunications modem adapter (41), which is 
built in in order to enable the link to an audiovisual 
information distribution network that is controlled by a central 
server . 

In order to reproduce the sound information of the musical 
selections, the system includes loudspeakers .( 54 ) that receive 
the signal from a tuner-amplifier (53), which is connected to 
electronic circuit (5) that incorporates two memory buffers (56, 
57) of the music synthesizer type that are supplied to support a 
large number of input sources while providing CD (compact disc) 
type output quality. . 
ly Likewise, th^iait^ra jiiza'tion m eans control circuit^also has 
two buffer memories (66, 67) for the purpose explained above. 

A 240-watt thermally regulated and ventilated power supply 
feeds power to the system. This power supply is protected 
against overcurrents and overdriving. 

By means of its input controller circuit (3), the 
audiovisual reproduction system manages a touch screen (33) , 
which includes a glass coating panel that uses the "advanced 
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surface-wave technology", .as well as an AT-type bus controller. 
This touch screeny^maJtes— it pos^ite4e^-a#be^--b avi n g dis pl a y e^/jon 
video monitor (62) or the screen of a television set (61) various 



selection data that are used by the customers, as well as 
management command and control data that are used by the manager 
or owner of the system. This touch screen is also used for 
maintenance purposes in combination with an external keyboard 
(34) that can be connected to the system which, for this purpose, 
has a keyboard connector that is controlled by a key lock (32) 
via interface circuit (3) . 
E 2 Input circuit (3) also interfaces the system with a remote 

V} control assembly (31) that consists of, for example, a radio 
^3 frequency RF remote control. 

fy A fee payment device (35) is also connected to input 

s interface circuit (3) . It is also possible to use any other 

C3 device that makes it possible to receive any kind of payment 

|J using coins, tickets, tokens, magnetic or microchip cards, or any 

n combination of these means of payment. 

To allow the system to be installed, it is equipped with a 
chassis or is built with customizable external fittings. 

In addition to these elements, a wireless microphone (55) is 
connected to sound controller (5); this makes it possible to 
convert the sound controller into a powerful public-address and 
information system or optionally into a karaoke machine. 
Likewise, the system can also use a wireless loudspeaker system. 
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Remote control assembly (31) allows the manager from, e.g., 
behind the bar, to access and control various commands such as: 

- the microphone ,on-off control; 

- the loudspeaker muting control; 

- the control for canceling the musical selection that is 
currently being played. 

Two buffers (56, 57) are associated with sound controller 
circuit (5) in order to make it possible to store, each 
alternately, a data item corresponding to at least approximately 
a quarter of a second of sound. Likewise, two buffers (66, 67) 
are associated with video controller circuit (6), whereby each 
buffer is able, either by itself or alternatively, to stor^ at 
least approximately one-tenth of a second of an image. Finally, 
a respective buffer (46, 36, 26) is associated with each of 
communications .controller circuit (4), input interface circuit 
(3) , and storage circuit (2) . 

The system operating software was developed around a library 
of tools and services that were very largely oriented toward the 
audiovisual domain in a multimedia universe. This library 
advantageously includes a high-performance multitask operating 
system that effectively allows the simultaneous execution of 
multiple fragments of code. This operating software also allows 
the concurrent execution, in an orderly and completely 
conflict-free way, of operations that are carried out on the 
display meaas and the sound reproduction^meax^s, as well as tne 
managing of the telecommunications links through the distribution 



10 




network. Moreover, this software is highly flexible. 

The operating system is divided into modules, which include 
a first boot module (7), which in turn is subdivided into a first 
main program module (70) "JUK.EXE", which checks the memory and 
verifies whether the minimum number of objects is available to 
ensure the operation of the jukebox; a second module (71), which 
is dynamically linked and is dependent thereon, is represented by 
the "JUKECORE.DLL" module. The function of^swaAd- second module 
(71) is to hold the libraries in C and to ensure the execution of 
the main task. 

The architecture of the operating system calls for the 
different tasks to be broken down into software modules that are 
connected to one another by dynamic links or consist of 
executable subroutines that have main dependence links to other 
parts of the operating system. Each of the modules is composed 
of object files or dynamic link library files that are organized 
according to a number of dependence levels described in the 
attributes. The attributes of an object or a library indicate 
the version number and the dependencies of the object or library 
file with respect to other object files, as described below for 
the PARSER module. Each attribute indicates the level attribute 
to the module. Thus, the JUK.EXE module (70) is of a higher 
level than the modules JUKECORE (71), TLS (72), CRDE (73), GFX 
(74), WDLL (75), JEEP (9) and TELECOM (10), but TELECOM module 
(10) is dependent on JEEP module (9) (see link 910), and is thus 
lower in level than JEEP (9) . 
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Likewise, JEEP (9) .(see link 759) is of a lower level than 
WDLL module (75), because it is dependent on it and TLS (725), of 
a higher level than WDLL (75) . However, TLS and GFX may be on 
the same level. The main task includes a module (JUKECORE) whose 
purpose is to initialize or load module (73), the nucleus of 
program "CRDE . DLL" , to initialize or load module (74) for 
managing graphics (GFX), to initialize or load module (75) for 
loading libraries (WDLL. DLL), to load Telecom module (10) for the 
task of telecommunications (DLL), to load TLS . DLL module (72), 
which contains all the uses required for the jukebox, for 
telecommunications, time, decryption, etc.,..., to initialize or 
load the library of JEEP (Juke Execution Exchange Protocol) 
programs, which handle the tasks of an integrity server, load 
request and dialogue with the server, and to launch program (80, 
SILOAD.DLL) as a main task. The main task of the jukebox 
application includes a module (SILOAD.DLL) that contains the 
library of the loader program whose purpose is to verify the 
dynamic link library versions required in (WDLL) , to load them or 
to call the tasks Y/ yQ Telecom module in order to transfer files. 
The WDLL. DLL module includes the list in a file ( DLL . DEFAULT ) of 
the versions that are required for operation, as well as the list 
of all of the functions that are represented by libraries 
(LIBRARY) (DLL, DJL) or by object files (DJO) . Each object or 
library contains the list of all of the functions that the 
library or object needs, as well as the version members and 
dependencies. The WDLL module manages all of the new modules, 




checks to verify the interdependencies, and verifies that the 
remotely loaded modules have no dependence and have been loaded 
with the required versions. Application part (8) that is 
inherent in a jukebox includes a certain number of modules that 
are loaded and launched by SILOAD and that define the "Windows" 
functions of the display, which include the following: 

- a module (81) for running the mouse or touch-screen 
signals; 

- a module (82) for running the messages that are exchanged 
between the objects and the various other modules; 

- a FIL.DLL module (83) for managing the files on disk; 
}|J - a read-write module (84) FILO.DJL for files on disk; 

l J . - a JSTRUCT.DJL module (85) for monitoring all of the events 

[*S produced by the hardware, such as the touch screen, the sound 
f. card, and the interface for processing fee hardware. 
13 SILOAD manages the loading of the modules that are specific 

W to the task of the terminal, i.e., all of the DJL modules already 
O listed above, as well as jukebox library modules (87), consisting 
of WOBJECT (870), which manages the objects such as the mixer and 
purchases; WCURSOR module (871), which manages the movements of 
the cursor; DBMAPI module (872), which manages the database; 
WFONTS module (873), which manages all of the types of fonts; 
PARSER (syntactic analysis program) module (874), which analyzes 
and generates the screens from the., script and verifies grammar 
with the aid of module "GRAMMAR. DJL" (876) and module "LEXY.DJL" 
(875), which is the lexical module that assigns the functions of 
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the words within the language. PARSER module (874) contains in 
its file header the following information: 

-char*parser _ version _ info = "DLL_INFO. DJL, " 

"DLL-NAME PARSER. DJL" 

"VERSION 1;" 

"CREATOR KEN DAL F; " 

"REQUIRES lexyy.djl; 4" 

"REQUIRES grammar-djl; 5"; 
All of the modules and all of the libraries (DJO, DLL, DJL) 
contain information similar to that of the PARSER module, and 
this information determines the needs in terms of versions and 
dependence . 

Thus, the PARSER module needs LEXY module version 4 and 
GRAMMAR module version 5 in order to allow it to be executed by 
the system. The double arrows in Figure 2, which connect the 
various modules to one another, indicate the order in which the 
different files are loaded. Thus, as indicated previously, it 
will be necessary to start by loading JUKE . EXE, then loading 
JUKECORE.DLL, and being able, from JUKECORE.DLL, to load GFX . DLL, 
TLS.DLL, WDLL . DLL, JEEP. DLL, TELECOM . DLL, CRDE . DLL, and 
SILOAD. DLL. 

The single arrows represent the dependencies between files. 
Thus, arrow (91) indicates that the DJL and, in particular, 
DBMAPI modules are dependent on CRDE. DLL. Arrow (93) indicates 
that the DJO files are dependent on the WOBJECT.DJL module. The 
WOBJECT.DJL module is itself dependent on the FILIO.DJL module.- 
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Arrow (92a) indicates that DBMAPI.DJL is dependent on 
JSTRUCT.DJL, and arrow (92b) indicates that DBMAPI.DJL is 
dependent on WMESSAGE . DJL . Arrow (98) indicates that JSTRUCT.DJL 
is dependent on the WMESSAGE. DJL file. WMESSAGE is dependent on 
the MOUSE. DJL file and, since FILIO.DJL is dependent on the 
FIL.DJL file, the file XCP.DJL is dependent, as indicated by 
arrow (856), on JSTRUCT.DJL and, as indicated by arrow (826), on 
WMESSAGE. DJL. The JHANDLER file is dependent, as indicated by 
arrow (97), on WMESSAGE. DJL and, as shown by arrow (96), on 
JSTRUCT.DJL. The SILOOP.DJL file is dependent, as indicated by 
i arrow (95), on JSTRUCT.DJL and, as indicated by arrow (94), on 

L ? WMESSAGE. DJL. The TELECOM. DLL file is dependent, as indicated by 

y 

3 arrow (910), on JEEP. DLL, which in turn is dependent, as shown by 
U arrow (959), on WDLL . DLL . The WDLL. DLL file is dependent, as 

indicated by arrow (725), on TLS.DLL. Likewise, arrow (89c) 
3 shows that GRAMMAR. DJL is dependent on LEXY . DLL and, as indicated 
j by arrow (99b), that LEXY. DJL is dependent on PARSER. DJL. Thus, 
5 as was seen previously, PARSER requires LEXY and GRAMMAR to 
execute itself, and version 1 of PARSER calls version 4 of 
LEXY. DJL and version 5 of GRAMMAR. DJL. Likewise, WOBJECT.DJL is 
dependent, as indicated by arrow (99a), on PARSER. DJL. Thus, all 
of the .DJO, .DLL, and . DJL modules and libraries contain 
information similar to that of the PARSER module, which 
determines the version requirements of the various modules on 
which a given module is dependent. This information also 
indicates the dependencies of the modules with respect to the 
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other modules, as indicated by the arrows in Figure 2. 

Library loading module SILOAD also loads or launches a 
module SILOOP.DLL (90), with an event wait tape. A set of 
modules (88) contains a list of the files that have to be 
included there to manage the windows of a Windows display that is 
provided on the monitor of the jukebox-type terminal. 

This list of objects consist of: 

- an object file (883) "WPSCREEN . DJO" , which makes it 
possible to define the main page on the monitor; 

- an object file (881) "WSCREEN", which makes it possible to 
J 2 determine on this main page the number of screens available and 

^ n thus to make it possible to display multiple windows or screens; 

CO 

u - an object file (880) "WIMAGE . DJO" , which makes it possible 

fU to determine and define on the screen the image that the screen 

L : : 

= will use; 

p - an object file (882) "WANIM.DJO", which makes it possible 

Is. 

Id to define the animation when the image is animated; 

q - an object file (885) "WBUTTON . DJO" , which makes it 

possible to define and manage the buttons that will be used on 
the screen of the main page, such as the actuation buttons used 
in the graphical interface that is defined in patent application 
PCT WO 96/12258; 

- an object file (884) "WLABEL . DJO" , which makes it possible 
to create labels that make it possible to write on top of an 
object; and 
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- an object file (886) "WSCROLLER. DJO" , which makes it 
possible to define the vertical-scroll display zones, 

A " JHANDLER" library makes it possible to define the fixed 
uses of the screens and thus to determine which are the 
interfaces that ensure the links to the different objects that 
are defined by the previous modules. 

Library module "XCP" (86) makes it possible to manage the 
payment tasks such as those of ticket receiving systems or coin 
or card payment units and also makes it possible to back up basic 
information in the IBUTTON, which is an integrated circuit for 
t storing secret codes for the user. 

s Thus, when .a new file is sent by remote loading to the 

1 system, the file contains information on its level, which depends 

* on the type of file. The files of the graphical images, for 

example WIMAGE.DJO, have the highest levels, and the hardware 
3 management files, for example XCP.DJL, have the lowest levels. 
J The JEEP module verifies the dependence logic by starting with 
3 the lowest-level files and moving up toward the higher files, all 
the while ensuring that the necessary dependencies between the 
files or libraries are respected. In this way, a modification in 
WOBJECT.DJL will cause JEEP to verify that the version 
information required by WO JBECT . DJL for the DJO files that are 
dependent and are required for its execution corresponds to the 
minimum versions required by the information recorded in the 
WOBJECT.DJO file. Thus, if WOBJECT.DJL requires a certain 
version of WPSCREEN . DJO, it will verify that this version is at 
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least present and that, if there is only a version of an 
inadequate level, it will report a problem. Then JEEP will go up 
the dependence links toward FILIO.DJL and FIL.DJL. 

The hard disk of the jukebox is organized in such a way as 
to comprise a directory C:\NEWJUKE, which contains the new 
jukebox files when new modules are remotely loaded. Another 
file, C:\OLDJUKE, contains a backup of the stable versions of the 
files and modules that are required for the operation of the 
jukebox. The JEEP (JUKE EXECUTION EXCHANGE PROTOCOL) module 
contains an automatic file manager that keeps track of the 
modules and files that are updated by backing up the old files 
for a certain period of time and by moving their files into the 
NEWJUKE directory. This task also copies the files on the tracks 
of the disk in the event that there is a sudden incident during 
the remote loading operation. The JEEP module also contains a 
reboot manager that is responsible for changing the execution 
level of the files of the jukebox once the automatic file manager 
has determined that an update of the jukebox has been 
accomplished. The JEEP. DLL module also generates a MISDEPS.DAT 
file when a missing dependence has been detected. This fixe 
contains lines in the form NEEDPARSER.DLL arrow version 2: 

NEEDLEXY.DLL -> version 2.0, etc This file allows the 

server, by reading this MISDEPS.DAT file, to determine the 
modules on the jukebox and to reload them. 

Other modifications within the grasp of one skilled in the 
art are also part of the spirit of the invention. 
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Translator 1 s notes : 



1. The term "auto-alimente" pertaining to static RAM (p. 6 
of the foreign, p. 4 of the English), was not found in available 
references and was thus rendered literally as "self-powered," but 
it may refer to the fact that such RAM is volatile, i.e., it will 
lose data if it has no power. 

2. The paragraph starting "A high-speed telecommunications 
E ? modem adapter..." (foreign page 6, English p. 5) is an incomplete 

* j j sentence. 

CO 

\3 3. The second sentence in the paragraph starting "By means 

fli of its input controller circuit (3),..." (foreign page 6, English 
s p. 5) is an incomplete. 

lj 

s . a 



